<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">

<html>
<head>
<title>Object Inheritance</title>

<STYLE type="text/css">
<!--
        .Default { font-family: verdana,arial,serif; font-size: 8pt; }
        .PageTitle { font-family: verdana,arial,serif; font-size: 12pt; font-weight: bold; }
-->      
</STYLE>

</head>

<body bgcolor="#FFFFFF" text="black" class="Default">

<p>
<div align="center">
<h2 class="PageTitle">Object Inheritance</h2>
</div>
</p>
<hr>

<p>
<strong><u>Introduction</u></strong>
</p>

<p>
This documentation attempts to explain object inheritance and how it can be used in <a href="xodtemplate.html">template-based object definitions</a>.
</p>

<p>
One of my primary motivations for adding support for template-based object data was its ability to easily allow object definitions to inherit various properties from other object definitions.  Object property inheritance is accomplished through recursion when Nagios processes your configuration files.
</p>

<p>
If you are still confused about how recursion and inheritance work after reading this, take a look at the sample object config files provided in the distribution.  If that still doesn't help, drop an email message with a <i>detailed</i> description of your problem to the <i>nagios-users</i> mailing list.
</p>

<p>
<strong><u>Basics</u></strong>
</p>

<p>
There are three variables affecting recursion and inheritance that are present in all object definitions.  They are indicated in red as follows...
</p>

<p>
<pre>
	define <i>someobjecttype</i>{
		<i>object-specific variables</i> ...
		<font color="red">name		<i>template_name</i></font>
		<font color="red">use		<i>name_of_template_to_use</i></font>
		<font color="red">register	[0/1]</font>
		}
</pre>
</p>

<p>
The first variable is <i>name</i>.  Its just a "template" name that can be referenced in other object definitions so they can inherit the objects properties/variables.  Template names must be unique amongst objects of the same type, so you can't have two or more host definitions that have "hosttemplate" as their template name.
</p>

<p>
The second variable is <i>use</i>.  This is where you specify the name of the template object that you want to inherit properties/variables from.  The name you specify for this variable must be defined as another object's template named (using the <i>name</i> variable).
</p>

<p>
The third variable is <i>register</i>.  This variable is used to indicate whether or not the object definition should be "registered" with Nagios.  By default, all object definitions are registered.  If you are using a partial object definition as a template, you would want to prevent it from being registered (an example of this is provided later).  Values are as follows: 0 = do NOT register object definition, 1 = register object definition (this is the default).  This variable is NOT inherited; every (partial) object definition used as a template must explicitly set the <i>register</i> directive to be <i>0</i>.  This prevents the need to override an inherited <i>register</i> directive with a value of <i>1</i> for every object that should be registered.
</p>

<p>
<strong><u>Local Variables vs. Inherited Variables</u></strong>
</p>

<p>
One important thing to understand with inheritance is that "local" object variables always take precedence over variables defined in the template object.  Take a look at the following example of two host definitions (not all required variables have been supplied):
</p>

<p>
<pre>
	define host{
		host_name		bighost1
		check_command		check-host-alive
		notification_options	d,u,r
		max_check_attempts	5
		<font color="red">name			hosttemplate1</font>
		}

	define host{
		host_name		bighost2
		max_check_attempts	3
		<font color="red">use			hosttemplate1</font>
		}
</pre>
</p>

<p>
You'll note that the definition for host <i>bighost1</i> has been defined as having <i>hosttemplate1</i> as its template name.  The definition for host <i>bighost2</i> is using the definition of <i>bighost1</i> as its template object.  Once Nagios processes this data, the resulting definition of host <i>bighost2</i> would be equivalent to this definition:
</p>

<p>
<pre>
	define host{
		host_name		bighost2
		check_command		check-host-alive
		notification_options	d,u,r
		max_check_attempts	3
		}
</pre>
</p>

<p>
You can see that the <i>check_command</i> and <i>notification_options</i> variables were inherited from the template object (where host <i>bighost1</i> was defined).  However, the <i>host_name</i> and <i>max_check_attempts</i> variables were not inherited from the template object because they were defined locally.  Remember, locally defined variables override variables that would normally be inherited from a template object.  That should be a fairly easy concept to understand.
</p>

<p>
<strong><u>inheritance Chaining</u></strong>
</p>

<p>
Objects can inherit properties/variables from multiple levels of template objects.  Take the following example:
</p>

<p>
<pre>
	define host{
		host_name		bighost1
		check_command		check-host-alive
		notification_options	d,u,r
		max_check_attempts	5
		<font color="red">name			hosttemplate1</font>
		}

	define host{
		host_name		bighost2
		max_check_attempts	3
		<font color="red">use			hosttemplate1</font>
		<font color="red">name			hosttemplate2</font>
		}

	define host{
		host_name		bighost3
		<font color="red">use			hosttemplate2</font>
		}
</pre>
</p>

<p>
You'll notice that the definition of host <i>bighost3</i> inherits variables from the definition of host <i>bighost2</i>, which in turn inherits variables from the definition of host <i>bighost1</i>.  Once Nagios processes this configuration data, the resulting host definitions are equivalent to the following:
</p>


<p>
<pre>
	define host{
		host_name		bighost1
		check_command		check-host-alive
		notification_options	d,u,r
		max_check_attempts	5
		}

	define host{
		host_name		bighost2
		check_command		check-host-alive
		notification_options	d,u,r
		max_check_attempts	3
		}

	define host{
		host_name		bighost3
		check_command		check-host-alive
		notification_options	d,u,r
		max_check_attempts	3
		}
</pre>
</p>

<p>
There is no inherent limit on how "deep" inheritance can go, but you'll probably want to limit yourself to at most a few levels in order to maintain sanity.
</p>

<p>
<strong><u>Using Incomplete Object Definitions as Templates</u></strong>
</p>

<p>
It is possible to use imcomplete object definitions as templates for use by other object definitions.  By "incomplete" definition, I mean that all required variables in the object have not been supplied in the object definition.  It may sound odd to use incomplete definitions as templates, but it is in fact recommended that you use them.  Why?  Well, they can serve as a set of defaults for use in all other object definitions.  Take the following example:
</p>

<p>
<pre>
	define host{
		check_command		check-host-alive
		notification_options	d,u,r
		max_check_attempts	5
		<font color="red">name			generichosttemplate</font>
		<font color="red">register			0</font>
		}

	define host{
		host_name		bighost1
		address			192.168.1.3
		<font color="red">use			generichosthosttemplate</font>
		}

	define host{
		host_name		bighost2
		address			192.168.1.4
		<font color="red">use			generichosthosttemplate</font>
		}
</pre>
</p>

<p>
Notice that the first host definition is incomplete because it is missing the required <i>host_name</i> variable.  We don't need to supply a host name because we just want to use this definition as a generic host template.  In order to prevent this definition from being registered with Nagios as a normal host, we set the <i>register</i> variable to 0.
</p>

<p>
The definitions of hosts <i>bighost1</i> and <i>bighost2</i> inherit their values from the generic host definition.  The only variable we've chosed to override is the <i>address</i> variable.  This means that both hosts will have the exact same properties, except for their <i>host_name</i> and <i>address</i> variables.  Once Nagios processes the config data in the example, the resulting host definitions would be equivalent to specifying the following:
</p>

<p>
<pre>
	define host{
		host_name		bighost1
		address			192.168.1.3
		check_command		check-host-alive
		notification_options	d,u,r
		max_check_attempts	5
		}

	define host{
		host_name		bighost2
		address			192.168.1.4
		check_command		check-host-alive
		notification_options	d,u,r
		max_check_attempts	5
		}
</pre>
</p>


<p>
At the very least, using a template definition for default variables will save you a lot of typing.  It'll also save you a lot of headaches later if you want to change the default values of variables for a large number of hosts.
</p>



<hr>

</body>
</html>
